I'll take a look

Did this start failing recently?

Did this start failing recently?

Yeah started failing this week. Appears the Dask version is the same between the pass/failing runs, but maybe it's because the numpy version is different between them (passes with 2.0.2, fails with 2.1.3)

Thanks for the ping.

Looks like numpy changed something under the hood that exposed a bug in Dask...

dask/dask#11697 fixes this

Looks like numpy changed something under the hood that exposed a bug in Dask...

dask/dask#11697 fixes this

Thanks @phofl!
Do I understand this correctly that our setitem code path with a dask array at some point goes through a np.array(arry_like, copy=False) call? (based on dask/dask#11697 (comment)) Because regardless of the fact that dask should align with upstream numpy and deprecate then raise if copy=False is not possible, this also seems something we should further investigate on the pandas side? (with CoW, I would think we shouldn't be setting an array-like with copy=False, but ensure we always set a copy of the values in the column)

@mroeschke and thanks for the CI fixes! For the numba failures, did this also start to happen with a new numba release? Are they aware of the issue?

And another segfault in pandas/tests/window/test_expanding.py

No, Dask was ignoring the copy kwarg and we were erroneously not copying by default if your array has a single chunk only. The copy kwarg of pandas was set to true

For the numba failures, did this also start to happen with a new numba release?

AFAICT, yes this happened when the Ubuntu ARM CI jobs started to install numba=0.61

Are they aware of the issue?

From a skim of the issue tracker, I don't think they are aware of the issue yet. But also, I haven't had a moment to come up with a MRE for the numba folks of the segfault

Now that we're finally green here, going to merge to get the CI to green.

Opened #60879 to follow up on creating a MRE to report to numba

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout 2.3.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 0a1577f2f0d1c9efda4b7b2d616177691d1ca73b

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #60847: TST/CI: skipif numba tests on Ubuntu ARM for numba 0.61'

4. Push to a named branch:

git push YOURFORK 2.3.x:auto-backport-of-pr-60847-on-2.3.x

5. Create a PR against branch 2.3.x, I would have named this PR:

"Backport PR #60847 on branch 2.3.x (TST/CI: skipif numba tests on Ubuntu ARM for numba 0.61)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.